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DECLARATION UNDER 37 CFR 1.131 OF STEVEN VIAVANT 
I, Steven Viavant, declare that: 

I am the first named inventor of the present application. 

'The invention recited in the claims of the subject patent application was actual ly reduced 
to practice in various versions of prototype software for Oracle Corporation's IAS 
software between December 15, 2000 and January 9, 2001, as indicated in the attached 
invention disclosure form that describes the invention claimed in the present patent 
application. 

The a ttached invention disclosure form does not include information about dates of 
conception. The invention recited in the claims of the subject patent application was, 
however, conceived and discussed among the co-inventors of the present patent 
application at least two days prior to the earliest actual reduction to practice of December 
15, 2000, or at least as early as December 13, 2000, 

From a time just prior to December 14, 2000 to the actual implementation of the 

invention in prototype software between December 15, 2000 and January 9, 2001, the 
inventors worked diligently to implement the invention recited hi the claims of the 
present application in the prototype software. 

I hereby declare that all statements made herein of my own knowledge are true and that 
all statements made on information and belief are believed to be true; and further that 
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these statements were made with the knowledge that willful false statements and the like 
so made are punishable by fine or imprisonment, or both, under Section 1001 of, Title 18 
of the United States Code and that such willful false statements may jeopardize, the 
validity of the application or any patent issued thereoi 
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Title: 
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Patent Application 

METHOD FOR WEB CLIENT RESPONSE-TIME MEASUREMENT 
Steven Viavant; Arsalan Farooq; Jaydeep Marfatia; Manu Shukla 
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Message: 



Hi Brian, I understand from Michael that a provisional will be filed on 
the enclosed invention disclosure. 




The information contained in this facsimile transmission is PRIVILEGED and CONFIDENTIAL, intended 
only for the individual named above. If you have received this transmission in error, please notify us by 
telephone immediately and return the original transmission to us at the above address via the U.S. 
Postal Service. Dissemination, distribution, or copying of this communication by anyone other than the 
intended recipient is strictly prohibited. 
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Date: Tue, 9 Jan 2001 18:49:56 -0800 (PST) 
Message-ID: <2Q0 1 0 11 00249 . SAA 1 6474@web 1 8 . us.oracle.co m> 
To: kathleen.a.rairell@oracie.com 
From: New-inventor us@oracie.com 
Subject: WEB INVENTION DISCLOSURE FORM 

Descriptive Title or Subject of the Invention: 

Method for web client response-time measurement 

Inventors: 

Steven Viavant, 90 Crocker, Piedmont, Ca 94611, (510) 420 8449, 

Arsafan Farooq! 2oM8Greenwich St., Apt#1 San Francisco, CA 9412 (415) 346 2926, 

Taydeep MaSa "3292 Colgate Ave, Santa Clara CA 95051, (408) 248 8963, manager is 

Man^Shukla^lO De Sabla Road Apt 304, San Mateo, Ca, 94402, (650) 342-6446, manager is 
Steven Viavant 
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Primary Development Group: ST-HQ 

Secondary Development Group: System Management Products 

Managing VP: Jay Rossiter 
Other VP: 

Description of problem: 

People use browsers on the net to effect all sorts of useful activities. Providers of web sites 
are interested to know how quickly their site is serving content to the people who come to it. 

One way of doing this Is to measure at the web site itself how quickly one is able to serve 
requests. However, this does not tell you what the 'customer* is really experiencing, since 
there are additional delays associated to network time, as well as for the client (e.g. PC) to 
actually render the content on its screen. 

Some companies try to approximate this measurement by running a set of distributed agents 
at different points on the internet, and having them periodically simulate a customer by 
downloading one or several specific html pages. This has the drawback that it only measures 
a few of the different activities (pages) on the site, and that although it measures these times 
from a variety of geographic locations, it doesn't measure them from the actual locations the 
customers are coming to the site from. And, it imposes gratuitous load on the system in the 
process, plus requires a separate out-of-band step to ship the measurements to the site which 
actually is interested in them. 

Another approach is to install some software on the client PC to measure these times. This 
approach has been taken variously by installing a specially instrumented replacement tcp 
stack, by installing a special device driver which maps in the memory of other device drivers 
and snoops on them, etc. This approach has the drawback that installing (and maintaining) 
software on the client is a very cumbersome thing, and has ail sorts of management 
headaches associated with reporting the measurements obtained across the internet, etc.. 

Yet another approach is to instrument the application (content) itself to take the measurements 
and report the results. This has the drawback that potentially thousands of separate 
instrumentation points need to be inserted and maintained in the code/content that constitutes 
the application. 

Description of the solution of the invention: 

Our approach Is to automatically instrument the content of the application using some generic 
javascript, which we append to the content as it is being served. This javascript is designed so 
that it may be appended to any HTML page, at the end of the page. It registers 'handlers' for 
certain key events, such as a page finishing rendering, or a user clicking on a submit button, 
etc. We use these handlers to capture client clock values, which we then automatically 
transmit back to the web site which served the original content, either using a cookie, by using 
the argument field of a fetch of a dummy (non-displayed) image, or using an html POST 
operation (each method has certain advantages over the others). This data is then mined from 
log files at the web server side (or in the case of using the POST operation, handled directly 
by a servelet). 

The automatic instrumentation can be effected in various manners. The existing prototype 
invention uses a "vanilla" Apache "mod". Other approaches investigated (and in various 
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stages of implementation) include using custom code inside the Oracle webcached, or altering 
the base servelet of the servelet engine being used. 



The pros and cons of the invention over status quo: 
See parts A and B. 

Significance of the new solution to Oracle: 

Any web site which deploys the Oracle stack will be able to obtain accurate, "click to eyeball" 
response time values for all of the content it serves, for any client, anywhere on the internet, 
for any application, without installing anything on the clients, or manually instrumenting their 
content. To our knowledge, nobody else can make this claim currently. 

This sort of info is valuable for providing Service Level Reports for hosting environments, 
which can serve as the basis for monitoring Service Level Agreements (especially in the case 
that there is a VPN or other network component involved, which the Application hosting entity 
takes responsibility for). 

This sort of information is also valuable In such an environment, in that it allows a service 
provider to have a window into the 'shop' of its customers, and enables reports to the 
customer as to which users should have their PC or network connection investigated for 
performance problems (i.e. we can look at a set of data, and see that repeatedly, at time Tjoe 
had response time of 42 seconds for an activity that most users received at time T in 7 
seconds; we don't know what joe's problem is, but we know that he has one. This allows joe's 
sys-admins to investigate and remedy the situation; also note that we can prioritize this list of 
"joes" by those whose productivity is most affected). 

This is also a good mechanism for finding content with pathological rendering problems, or 
problems relating to certain browser type or browser version only (and to ignore such potential 
problems if your actual user base is not using the browser type or version which would trigger 
the problem). 

This invention could also be used to find out which clients have problems with apps with large 
or complicated content, and could be used to drive an automated 'adaptive' choice of simple 
vs. complex versions of the same content to serve, depending on apparent (measured) client 
capacity, 

This technique could also provide data to trending calculations, to obtain advance notice of 
gradual deterioration of response times, as well as to drive 'events' (e.g. email or pagers) in 
the event of sudden, steep degradation in response time, to alert a sys-admin to respond (or 
to automatically begin shedding or redirecting load, or serve the 'lightweight' version of 
content, etc). 

This sort of data could also be used to debug complex site administration problems, by 
narrowing the time frame to those slots which actually had a negative affect on customer 
performance. For example, a site typically gathers a large number of metrics (cpu, memory, 
disk, database-buffer-cache, etc), there may easily be upwards of hundreds of such metrics 
monitored on the different tiers and stacks deployed at a site. Each of these metrics may at 
various times spike or exceed 'comfortable' thresholds. However, some of the time this may 
have no affect on the end-users of the site, other times It may have grave ill effects on them. 
By being in possession of the data telling us specifically when customers had problems, we 
can mine our other system management data in an intelligent way, and focus our attention 
quickly on the particular metric-threshoid-vlolations which were likley to have contributed to 
real problems, as opposed to those which were benign, [which if we automated m! 
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ight in fact be the basis for a separate disclosure...]. 

And in general, it is just nice to get a handle on the response time that your real customers are 
actually experiencing. 

Does it add or enhance functions or features? Yes 

Does it increase performance for existing functionality? No 

Does it pertain to an interface? No 

Is it detectable by an end user. DBA, or SysAdmin? Yes 

is it applicable to products or environments outside of Oracle? 

The same technique could be used in conjunction with any Web server, not only with Oracle 
IAS. 

Has ft been implemented? Yes , 

If so, when? prototypes with various degrees of completeness over the period 12/1 5/00 to 

present. 

Has it been disclosed outside of Oracle? No 

if so, was it disclosed under a Non-Disclosure Agreement? 

Description of any disclosure outside of Oracle: 



Description of any products that use the invention, currently or planned: 

Anticipated with 9i IAS release 2, approximate dates of Beta 5/01, production 9/01 . Possible 
candidate for release in patch version of 9i IAS release 1, before then. 



Kathleen Farreil <kathieen.a.farretl@oracle.com> 
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